LSD Docs/LSD Docs.iso/FILEZ/lsd39.dms/lsd39.adf/AmosAlmanac.doc.pp/AmosAlmanac.doc

Text File | 1978-01-05 | 94KB | 2,365 lines

                   T H E   K E N T   T E A M   P R E S E N T


               T H E   C O M P L E T E   A M O S   A L M A N A C


                            I N T R O D U C T I O N


As this series was originally printed one article at a time and backed up by
monthly CoverDisks, you may find at times that the text assumes that, for
instance, you have a few sprites or a background picture on which to practice.
These files would have been supplied with the original article. Simply
substitute example files from the Amos program disks when this situation
arises.


Issue 42 ­ November 1991
` Putting together various previously discussed "modules" as the Pacman game
begins to take shape

Entertainment software is big business now, and people have to be a little bit
more creative to produce a good game, something which can be distinctly
different to a good seller! Hopefully Amos will help you to spend a lot more of
your time exercising these creative energies.

One important thing to remember about games software is that a lot of
programmers cheat. We have covered different methods of `cheating` in previous
issues. Some of the most amazing effects seen in games are, in fact, merely
illusion ­ screen swapping, colour cycling and palette switching are just some
of the ways to get amazing results without compromising the speed of your
program.

Almost anybody can use these methods, but the real skill is in integrating them
with the software so that they are invisible to the player, while at the same
time making him or her think `wow, I wonder how they did that`?.

OK, the first step in any piece of software is to set up your screen, we`ve
done all of this before ­ if you missed it then buy the back issues ­ so I
won`t take you through all of the old details again:

        ' Set up
        Screen Open 0,320,200,16,Lowres
        Curs Off
        Flash Off
        Cls 0
        Get Sprite Palette
        Double Buffer
        Autoback 0

Now we have the task of initialising all of the variables that we will use.
Although Amos ­ and most other versions of Basic for that matter ­ does not
require you to do this, it is a habit you should get into. After all, you won`t
be using Amos forever, will you`

We will need to keep track of the X and Y position of our character, so we will
use two variables call X_GOOD and Y_GOOD. As well as storing the position of
our character the joystick status will have to be stored, so we will call that
variable WAY:

        X_GOOD=150
        Y_GOOD=100
        WAY=0

Of course we will also need to move the bad guy around, so we will call its X
and Y co-ordinates X_BAD and Y_BAD:

        X_BAD=0
        Y_BAD=0

Finally we may want to introduce individual speeds for each of the characters
in the game, so we will call these ­ guess what?  ­ GOOD_SPEED and BAD_SPEED.
Notice that by using meaningful variable names we can tell a glance what a
particular section of code is doing, but be careful of falling into the trap of
ending up with variable names 40 characters long ­ they can be a real drag to
type in!

        GOOD_SPEED=1
        BAD_SPEED=1

Ohhhh, I almost forgot. This game is very simple and because of this it is
going to be blindingly fast, so in order to slow it down we will only update
everything occasionally. It sounds strange I know, but all will become clear
very soon.
        The variable we are going to use to control this is called T ­ or time!
­ and the variable used to hold the score is called SCORE:

        T=1
        SCORE=0

Now we have to stick the player and the bad guy on to the screen. For this
example program we are using BOBs, but you could use hardware SPRITEs:

        Bob 1,X_GOOD,Y GOOD,1
        Bob 2,X_BAD, Y_BAD,2

Now for the main part of the game:

        Repeat

The first line here tells the program that we only want to execute everything
inside the IF structure when the variable T has a value of two. At the moment
it only has a value of one:

        If T=2

Our next task is to check the joystick to see if a movement has been made. We
will use the JOY() function rather than the JUP/JDOWN functions, because it is
more versatile. A fuller explanation as to why this is will be given in the
next issue.
        We store the current joystick value ­ which is a number between 0 and
16 ­ in the variable WAY. If WAY has a value greater than zero then we know
that the joystick is being moved, and we can then test the direction and move
our character:

        WAY=Joy(1)
        If WAY>0

At this point we know that our man has moved so we can increase the score by
one:

        Inc SCORE

Now comes the joystick testing bit. In a previous issue we saw how the JOY()
function returns values depending on how it is currently positioned. Just to
recap, these are the values for the four basic directions: UP=1, DOWN=2,
LEFT=4, RIGHT=8.
        Knowing this we can see if the player wants to move the character and
so can increase/decrease the X_GOOD/Y_GOOD variables accordingly:

        If WAY=8
                Add X_GOOD,GOOD_SPEED,0 To 319
        End If
        If WAY=4
                Add X_GOOD,-GOOD_SPEED,0 To 319
        End If
        If WAY=1
                Add Y_GOOD,-GOOD_SPEED,0 To 199
        End If
        If WAY=2
                Add Y_GOOD,GOOD_SPEED,0 To 199
        End If

Another trick when writing a game is not to update anything on the screen
unless it has moved. For this reason we will only redraw our little character
when the joystick has been moved:

        Bob 1,X_GOOD,Y_GOOD,1
        End If

Here is a tricky question, with a very simple answer. How do you make a nasty
home-in on your good guy? Well, imagine you were playing a game where you had
to run after somebody. The brain would follow a simple set of rules, like: `If
the person is to the left of me, I must move left,` and, `if the person is in
front of me I must move forward.`

        These are the simple rules we can follow to make a `homer`. Of course
most games have a slightly longer list of rules to control movement of bad guys
and good guys, but at the end of the day they are still only a list of rules
that the program must
ollow.
        I am sure you have played many games where after a while you realise
that if you perform a certain action at a certain point, you can make the
program do the same thing almost every time. This is because it is just
following a set of simple ­ or com
licated ­ rules:

        If X_GOOD<X_BAD
                Add X_BAD,-BAD_SPEED
        Else
                Add X_BAD,BAD_SPEED
        End If
        If Y_GOOD<Y_BAD
                Add Y_BAD,-BAD_SPEED
        Else
                Add Y_BAD,BAD_SPEED
        End If

At this point we update the position of the bad guy and increase the value of
the variable T. Remember that the ADD statement below has been written so that
the number will wrap around from 1 to 2:

        Bob 2,X_BAD,Y_BAD,2
        Add T,1,1 To 2

As we have seen earlier, to slow the game down we only update characters every
second time we go through the loop. If the value of T is not 2 the program will
just execute the next couple of lines and go back to the beginning:

        Else
                Add T,1,1 To 2
        End If

Finally, we must set a stop condition on the REPEAT/UNTIL loop. In this case
the program will stop if Bob number one collides with any other Bob. If a
collision is detected your score is printed and the game ends!

        Until Bob Col(1)
        Boom
        Print `YOU ARE DEAD!!!! YOUR SCORE IS`;SCORE
        Update
        End

How long can you run around avoiding the nasty invader type beastie`. Why not
experiment a little bit and see if you can add more bad guys and perhaps
objects to collect. Before long you could be writing the follow up to
Llamatron!

Finally, do not try to compile the game unless you slow it down, because it
will end up impossibly fast! Remember that no piece of software is fixed, and
if you do not like something about a game you write then change it!


Issue 43 ­ December 1991
` Adding a maze to the rapidly developing Pacman game

Last month we saw how to get the good guy under joystick control and how to
make the bad guy follow him. This month we will take a look at how to put a
maze up on the screen.

OK, if you look at the screenshot on this page you should spot a nice picture
of some maze blocks. In fact there are eight in total, four corners, two
straight pieces, a small blob thing and a collectable pill (was Pacman a
junkie?).

Why use blocks to build up a maze? The answer is simple ­ flexibility. By using
blocks we can generate lots of different mazes using up only a fraction of the
memory that a picture would take up.

If you take another look at the picture of the blocks you will notice they have
numbers underneath. These will be used to build up our mazes. For example to
build up a simple border we would use the following data:

        DATA "12222222222222222223"
        DATA "4                  4"
        DATA "4                  4"
        DATA "4                  4"
        DATA "4                  4"
        DATA "4                  4"
        DATA "4                  4"
        DATA "4                  4"
        DATA "4                  4"
        DATA "4                  4"
        DATA "4                  4"
        DATA "52222222222222222226"

The number one represents the top left-hand corner and the number six
represents the bottom-right.
        To display this on-screen requires a little more work. The first thing
to do is to dimension an array to hold the maze data. As each block is 16 x 16
pixels our maze can only be made up of 20 blocks across and 12 blocks down.
Because we are going to
hold the block numbers in a string array we only need to dimension it to 11
elements:

        Dim MAZE$(11)

The next step is to open up to a lo-res screen and clear it ready for drawing:

        Screen Open 0,320,200, 16, Lowres
        Flash Off
        Curs Off
        Cls 0
        Get Icon Palette

I have already prepared an icon bank for you on the CoverDisk which must be
loaded into this listing before it will work:

        Load "MAZE_ICONS.ABK"

Things start to get a little more complex now. First we must read in a line of
our maze data:

        For LOP=0 To 11
        Read MAZE$(LOP)

Next we have to look at each part of that string to find out what maze block we
would like to position on the screen at the next point:

        For LOP2=0 To 19
        BLOCK-Val(Mid$(MAZE$(LOP), LOP2+1,1))

I always like to be careful when writing something like this. It is very easy
to mistype a character so it is always worth putting a check in for strange
values. Using this method we can automatically generate spaces in the maze if
we want them while avoiding any error messages which Amos would throw up if we
tried to display an icon that did not exist:

        If BLOCK>0 and BLOCK<9
        Paste Icon LOP2*16,LOP*16,BLOCK
        End If
        Next LOP2
        Next LOP

The maze!

        Data "12222222222222222223"
        Data "48888888888888888884"
        Data "48123812381223812384"
        Data "484 485268522684 484"
        Data "484 488888888888 484"
        Data "48526812222223852684"
        Data "4888884      4888884"
        Data "48123852222226812384"
        Data "484 488888888884 484"
        Data "48526812222223852684"
        Data "4888884      4888884"
        Data "5222226      5222226"

Erm? What next? Well, it's a bit of a surprise actually. The method I have just
showed you to draw the maze screens is OK, but we need a quick way to look at
the maze shape to find out where the blocks are.

This way we can control the movement of any creatures we decide to put into the
maze without resorting to slow and complex collision detection commands.

So we will now put all of the data needed to create a maze into an Amos memory
bank which will be 240 bytes long (20 blocks wide x 12 blocks tall):

        Reserve As Work 10,240

We now have to set up that funky screen and load those icons again:

        Screen Open 0,320,200,16,Lowres
        Flash Off
        Curs Off
        Cls 0
        Get Icon Palette
        Load "MAZE_ICONS.ABK"

This time we will read the data into memory bank 10 which we reserved earlier:

        For LOP=0 To 11
        Read MAZE$
        For LOP2=0 To 20

        BLOCK=Val(Mid$(MAZE$, LOP2+1,1))

Take note of the formula that is used to calculate the position of each block ­
we will use a slightly adapted version of this for collision detection:

        POSITION=Start(10)+(LOP*20)+LOP2
        Poke POSITION,BLOCK
        Next LOP2
        Next LOP

Once that is stored we can draw the screen by reading the data.

Simple formula time! Next month when we start to more our pacman around the
maze, and will need a routine to make sure it does not career into any walls.
We can find this out by constantly keeping a track of the position of our
pacman and then using the following formulae to see if any walls blocks its
path:

        UP=((Y-1)*20)=X
        DOWN=((Y+1*20)+X
        LEFT=(Y*20)+(X-1)
        RIGHT=(Y*20)=(X+1)

If that seems a little bit confusing don't worry, everything will become clear
as mud (sorry crystal)...


Issue 44 ­ January 1992
` Making our pacmen move around the maze

In the days before hardware sprites and automatic collision detection,
programmers still managed to produce games by looking at position of players,
enemies and background objects.  They could then calculate whether or not they
overlapped.

The first thing we must do to do this is set a working screen and load the
Pacman sprites and maze icons in memory:

        Reserve As Work 10,240
        Screen Open 0,320,200,16,Lowres
        Flash Off
        Curs Off
        Cls 0
        Hide On
        Load `MAZE ICONS.ABK`
        Load `PACMAN_SPRITES.ABK`
        Get Icon Palette

OK, now we must define some simple variables.  Those of you who have just
started to learn how to program will notice the GLOBEL statement. This lets our
program know that the variables X and Y are used in all parts of the program
(including procedures).


If we did not execute this command, the procedures - which are really mini
programs, independent of the main one ­ would assume that the variables X and Y
were used only in themselves. It is probably easier to think of the GLOBEL as
making the proced
res share information:

        Globel X,Y
        X=1
        Y=1
        MAKE_MAZE

OK, now is the interesting part. The formulas which are calculated into the
variables UP, DOWN, LEFT and RIGHT check the position of our Pacman compared
the maze data we have stored in
bank 10.

If the joystick is pushed in a direction and there is a pill found there, the
program will move the Pacman and erase the dot accordingly! If you remember how
we built up the maze last time you will recall that the pills had a value of
eight:

        Repeat
                UP=((Y-1)*20+X
                DOWN=((Y+1)*20+X
                LEFT=(Y*20)+(X-1)
                RIGHT=(Y*20)+(X+1)
                Bob 1,16*X,16*Y,2
                Wait 2
                WAY=Joy(1)
                If WAY<>0
                        If WAY=1 and Peek(Start(10)+UP)=8
                                EACH_DOT
                                Dec Y
                        End If
                        If WAY=2 and Peek(Start(10)+DOWN)=8
                                EAT_DOT
                                Inc Y
                        End If
                        If WAY=4 and Peek(Start(10)+LEFT)=8
                                EAT_DOT
                                Dec X
                        End If
                        If WAY=8 and Peek(Start(10)+RIGHT)=8
                                EAT_DOT
                                Inc X
                        End If
                End If
   Until False
   End

This procedure erases the pill when the Pacman moves:

        Procedure EAT_DOT
                Cls O,X*16+6,Y*16+6 To X*16+12,Y*16+12
        End Proc

The following procedure is identical to the one we wrote last month to draw the
maze:

        Procedure MAKE_MAZE
                For LOP=0 To 11
                        Read MAZES
                        '
                        For LOP2=0 To 20
                                BLOCK=Val(Mid$(MAZES,LOP2+1,1))
                                POSITION=Start(10)+(LOP*20)+LOP2
                                '
                                Poke POSITION,BLOCK
                                '
                        Next LOP2
                        '
                        For LOP=0 To 11
                                For LOP2=0 To 19
                                        BLOCK=Peek(Start(10)+(LOP*20)+LOP2)
                                        If BLOCK<>0
                                        Paste Icon LOP2*16,LOP*16,BLOCK
                                End If
                        Next LOP2
                Next LOP
                Wait Vbl
                Double Buffer
                '
                Data `12222222222222222223`
                Data `48888888888888888884`
                Data `48123812381223812384`
                Data `484 485268522684 484`
                Data `484 488888888884 484`
                Data `48526812222223852684`
                Data `4888884      4888884`
                Data `48123852222226812384`
                Data `484 488888888884 484`
                Data `48526812222223852684`
                Data `4888884      4888884`
                Data `5222226      5222226`
        End Proc


Issue 45 ­ February 1992
` Introducing ghosts to chase your pacman

As you will recall, we have now generated our maze and made a Pacman travel
around it with our joysticks ­ now it`s time to introduce a nice ghostie to
chase you. Some of the code we will be looking at will be familiar to you, but
there are subtle differences between the program we looked at in the last issue
and this one.

First we open our screens and reserve our bank to store the maze data. Then we
load in the sprites and icons:

        Reserve As Work 10,240
        Screen Open 0,320,200,16,Lowres
        Flash Off
        Curs off
        Cls 0
        Hide On
        `
        Load `PACMAN_SPRITES.ABK`
        Load `MAZE_ICONS.ABK`
        Load `MAZE_ICONS.ABK`
        Get Icon Palette

Note that most of the code is now in separate procedures. This is to keep
matters a little clearer when explaining things. As you write your own programs
you will find it much more efficient to break them down into smaller, more
manageable parts. This means that all of our variables must be declared as
Global ­ if we do not do this, our procedures will not recognise them!

The next step is to generate the maze and execute the main loop:

        MAKE_MAZE
        Repeat
        Wait 2

Right, because we have changed things a little, the program now checks the
joystick and moves our pacman by calling two procedures:

        CHECK_STICK
        DO_PACMAN

Because our ghost is moving quite quickly we need to weigh the odds in our
favour a little. To do this we will use a variable counter called PASS. Every
time the loop is executed we increment this variable, and when it reaches three
we move the ghost. So for every three moves we could make, the ghost will make
one:

        If PASS=3
        DO_GHOST
        End If
        Add
        PASS,1,1 To 3

Finally, we will check to see if the ghost has hit the Pacman by comparing
their co-ordinates. BX & BY are the ghost`s position X & Y are the Pacman`s
position in the maze:

        Until(BX=X and BY=Y)
        End

The next procedure is the one which makes the ghost so hard to beat. Remember
how a couple of issues ago we looked at baddie intelligence` This program uses
exactly the same method and follows these rules:

1] IF PACMAN IS LEFT OF GHOST THEN MOVE GHOST LEFT ELSE MOVE GHOST RIGHT

2] IF PACMAN IS ABOVE GHOST THEN MOVE GHOST UP ELSE MOVE GHOST DOWN

Of course, if a wall is in the way the pacman cannot move. You can easily
overcome this by introducing more complex rules. Remember ­ baddie intelligence
is always governed by a set of rules, simple or complex:

        Procedure DO_GHOST
        If BX<>X
         GHOST_RIGHT
        Else
         If BX>X
          GHOST_LEFT
         End If
        End If
        If BY>Y
         GHOST_UP
        Else
         If BY<>Y
          GHOST_DOWN
         End If
        End If
        Bob 2,16*BX,16*BY,4
        End Proc

The following procedures check to see if a wall is in the way before moving the
ghost. Any value found in the maze band other than eight is classified as a
wall. In more complex versions of the game you could check for power pellets,
bonus fruits, and so on:

        Procedure GHOST_LEFT
        B LEFT=(BY*20)+(BX-1)
        If Peek(Start(10)+B_LEFT)=8
         Dec BX
        End If
        End Proc
        Procedure GHOST_RIGHT
        B_RIGHT=(BY*20)+(BX+1)
        If PEEK(Start(10)+B_RIGHT)=8
         Inc BX
        End If
        End Proc
        Procedure GHOST_UP
        B_UP=((BY-1)*20)+BX
        If Peek(Start(10)+B_UP)=8
        Dec BY
        End If
        End Proc
        Procedure GHOST_DOWN
        B_DOWN=((BY+1)*20)+BX
        If Peek(Start(10)+B_DOWN)=8
        Inc BY
        End If
        End Proc

CHECK_STICK looks at the value stored in JOY(1). This contains a bitmap of the
joystick position. If the value found is one it means that you are pushing the
joystick up, two means down, four is left and eight is right. Just for
reference, if the value of 16 is found then you have pressed Fire on the
joystick!

        Procedure CHECK_STICK
        WAY=Joy(1)
        If WAY<>>0
         If WAY=1 and Peek(Start(10)+UP)=8
         EAT_DOT
         Dec Y
         End If
         If WAY=2 and Peek(Start(10)+DOWN)=8
          EAT_DOT
          Inc Y
         End If
         If WAY=4 and Peek(Start(10)+LEFT)=8
         EAT-DOT
         DEC X
         END IF
         IF WAY=8 AND Peek(Start(10)+RIGHT)=8
          EAT_DOT
          Inc X
         End If
        End If
        End Proc

This procedure does exactly the same as the routine we looked at last month.
Basically it looks at the four directions surrounding the pacman to discover if
a wall is in the way. It stores this information in the global variables UP,
DOWN, LEFT, RIGHT:

        Procedure DO_PACMAN
        UP=((Y-1)*20)=X
        DOWN=((Y=1)*20)+X
        LEFT=(Y*20)+(X-1)
        RIGHT=(Y*20)+(X+1)
        Bob 1,16*X,16*Y,2
        End Proc

The next procedure does, guess what? Yes it erases the dot!

        Procedure EAT_DOT
        Cls 0,X*16+6,Y*16+6 To X*16+12,Y*16+12
        End Proc

Finally comes the procedure to generate the maze, which we looked at in depth a
couple of issues ago.

        Procedure MAKE_MAZE
        For LOP=0 To 11
         Read MAZE$
         `
         For LOP2=0 To 20
          BLOCK=Val(Mid$(MAZE$,LOP2+1,1))
          POSITION=Start(10)+(LOP*20)+LOP2
          `
          Poke POSITION,BLOCK
          `
         Next LOP2
        Next LOP
        `
        For LOP=0 To 11
         For LOP2=0 To 19
          BLOCK=PEEK(Start(10)+(LOP*20)+LOP2)
          If BLOCK<>>0
           Paste Icon LOP2*16,BLOCK
          End If
         Next LOP2
        Next LOP
        Wait Vbl
        Double Buffer
        `
        Data "12222222222222222223"
        Data ...


Issue 46 ­ March 1992
` Taking a break from Pacman, and looking at Easy Amos, as well as some
Funschool tips

Easy Amos is basically a version of Amos which has been designed for people who
don`t know much about computer programming but want to learn, as well as people
who know a little but find Amos just a little too daunting.

To describe it as a cut down version of Amos is a little unfair ­ there are a
few commands and facilities which are missing (like menus) but it makes up for
them with some really great new ones (like commands to load and play
Soundtracker music without conversion!).

Easy Amos really is looking splendid. The manual ­ written by computer veteran
Mel Croucher ­ is humorous and informative and incorporates lots of cartoons.
There are loads of example programs on the accompanying disk which are
documented and discussed in the manual, so there is only a little typing for
those keyboard-shy beginners!

The whole appearance of the user interface has changed since its parent (Amos)
was written. Everything is made up from the grey relief type boxes which we are
so used to seeing in Workbench 2, and the editor now uses an eight colour
screen to improved the rather bland look associated with four colour examples.

Everything about Easy Amos oozes friendliness. You can customise the actual
language and the accompanying demos with your own name! It really is aimed at
the absolute beginner.

One of the more advanced features of this new Amos is the Tutor. It is, in
fact, a full source code debugger which will allow you to single step through
your program in order to test it. You can set up break points and even set your
own screens, Bobs, text and graphics up in a shrunk down window.

This is really amazing and has to be seen to be believed. I understand that
Europress Software will be taking this feature and adding it to an improved
`full` version of Amos currently dubbed `Amos II`. Roll on that day!!!

HERE`S a fabo tip for all of you programming Fun School 4 owners. On the Under
5s and 5 to 7s package a new experimental sound extension has been used! This
is compatible with the StarTrekker program (a SoundTracker clone) and will
allow you not only to play Soundtracker modules without using that dodgy
converter but also supports the synthetic instrument/Sound FX option in
StarTrekker!

The file is called `MUSIC.LIB` and is a direct replacement for the `MUSIC.LIB`
file contained inside your `Amos_SYSTEM` directory, so all you have to do is
copy it across. Unfortunately I do not have any details of the playing commands
so you will have to route around the FS4 programs for more information about
that.


Issue 47 ­ April 1992
` An introduction to AMAL, the powerful Amos sub-language

Now it's time to really break free and attempt a task using something really
meaty (or soya-beanie) if you are vegetarian) ­ AMAL.

We have covered AMAL previously, but not to write a whole game. Over the next
couple of issues I will be showing you how to get the most out of this sub-
language and more importantly how to use it in conjunction with the other (less
powerful) parts of Amos.

You will notice that I have referred to AMAL as a sub-language. This is because
it is a separate part of Amos and is quite capable of existing by itself. In
many respects AMAL is similar to assembly language, especially in its use on
mnemonics to represent the commands we use to create an AMAL program, and like
assembly language, it must be well structured in order to keep tracks of any
tasks we may ask of it.

To control AMAL we use a series of Channels ­ 16 in all. These can be assigned
to control a single AMAL mini-program which will run alongside your main Amos
program. Let's look at a way of using of AMAL. First we set up an AMAL channel
using a command like this:

        Channel 1 To Screen Display 0

This would prepare your channel to accept an AMAL program. Now we will tell
AMAL to feed the mouse co-ordinates into the external registers RA and RB,
after which we will read and display them onscreen.

One thing to remember about AMAL is that you must type it exactly otherwise
errors can occur quite easily. This is due to the fact that AMAL is case
sensitive ­ that is, it can tell the difference between upper and lower case
letters:

        mal 1,"Start: Let RA=XM ; Let RB=YM ; Jump Start ; "
         Amal On1
         Repeat
            Print At(0,0);Amreg(0);" "
           Print At(0,1);Amreg(1);" "
         Until False

AMAL registers are like ordinary variables in Amos itself, and can be used to
store numbers for calculations or later use. These are two types of AMAL
register, internal and external. The internal registers are labelled R0 to R9
and are mainly used for temporary storage of values within an AMAL program. The
external registers are labelled RA to RZ and are (or at least should be) used
for communicating with the outside world.

Reading these registers from your main Amos program is simple ­ we just use the
AMREG() command (see your Amos manual for a fuller explanation of AMREG).
Incidentally, you can store values in the AMAL registers from your main Amos
program once again using the AMREG() command..

Being a fully featured sub-language means that AMAL programs can be quite long.
For this reason AMAL allows you to structure commands within strings. I know it
sounds a little weird but you do get used to it ­ trust me!

In the previous example we saw how to create a simple loop jumping from the end
of the string back to the label "Start". Labels used for structuring AMAL
programs are all single letters of the alphabet, in upper case. Because AMAL
ignores all lower case letters you can pad out the label to create something a
little more meaningful.

The next example is made up of may smaller strings "glued" together t create a
single long string. You don't really want to know this but joining two or more
strings together is known as concatenation:

        Channel 0 To Screen Display 0
        A$="   Start:"
        A$=A$+"      Pause ; "
        A$=A$+"      Let Y=YM-100 ; "
        A$=A$+"      If XM-160<64 Jump Start ; "
        A$=A$+"      Let X=XM-160 ; "
        A$=A$+"Jump Start ; "
        Amal0,A$
        Amal On 0

This program will work in direct more and will allow you to move the default
screen around with the mouse. It's a little like the larger program which
appeared last month.

Notice the way I have put each command on a separate line. I have also padded
out the short labels and commands with lower case letters so that should I come
back to the program in a couple of months I will be able to work out what it
does quite easily.

AMAL also allows you to execute a simple form of FOR`NEXT loop, the main
difference between the AMAL version and the actual Amos version of the loop is
that you cannot perform STEPs (if you are unsure what a STEP is, check your
Amos manual). The following example does the same job as the previous program,
but only for a limited amount of times:

        Channel 0 To Screen Display 0
        A$="   For R0=1 To 80"
        A$=A$+"Start: "
        A$=A$+"      Pause ; "
        A$=A$+"      Let Y=YM-100 ; "
        A$=A$+"      If XM-160<64 Jump Start ; "
        A$=A$+"      Let X=XM-160 ; "
        A$=A$+"Next R0 ; "
        Amal0,A$
        Amal On 0

If you look at the Amosteroids game which came with Amos you will see that most
of the work is dome by AMAL ­ it controls the starship and asteroids. In fact
the only things Amos has to do is play the samples and update the score during
the game.

These AMAL programs need not be limited to controlling aliens in Xenon MXXIIX ­
how about using them to make Bobs to follow your mouse` Or making constant
calculations and feeding them into your main program using the AMAL registers?


Issue 48 ­ May 1992
` Rewriting the Pacman game to take advantage of AMAL

If you can cast your mind back a couple of months, we were playing around with
simple Bob movements using Amos. Our goal was to create a small Pacman game,
which we did. Now we will look at a different method of creating such a game,
using the Amos sub-language AMAL.

We took a look at the major AMAL functions in the last issue so I won`t be
going into too much fine detail concerning the basic functions. Instead we will
concentrate on the structure of an AMAL program.

The first thing to do is load in the Bobs for the game and set up our default
screen stuff. If you are unsure how to get these Bobs loaded in ­ trust me when
I say it`s not quite as straightforward as it sounds..

        Load `GAME_SPRITES.ABK`
        Screen Open 0,320,200,16,Lowres
        Curs Off
        Flash Off
        Cls 0
        Get Sprite Palette
        Double Buffer
        Autoback 0

Now comes the time to define our AMAL string. As you can see, I have built the
program up into the string A$. AMAL ignores spaces so I have taken advantage of
this to produce a clear piece of code which is easy to look at and ­ hopefully
­ to understand.

The first line sets up a label `Start:` and after a brief pause stores the
current joystick value in the register R0:

        A$=" Start: Pause ; Let R0=J1 ; "

By using comparisons we can then jump to routines depending on the current
joystick action. As I have said before, the numbers returned by the joystick
are 1=up, 2=down, 4=left, 5=right and in turn 9=up plus right (8+1=9), 6=down
plus left (2+4=6) and so on.

        A$=A$="   If R0&8 Jump Right ; "
        A$=A$="   If R0&4 Jump Left  ; "
        A$=A$="   If R0&1 Jump Up  ; "
        A$=A$="   If R0&2 Jump Down  ; "
        A$=A$="   Jump Start     ;

The next four routines perform the actual movements of the Bob ­ for more
details of how the Move command works see your Amos manual.

        A$=A$+"Right:           ; "
        A$=A$+"    Move 10,0,2     ; "
        A$=A$+"    Jump Start     ; "
        A$=A$+"Left:           ; "
        A$=A$+"    Move -10,0,2    ; "
        A$=A$+"    Jump Start     ; "
        A$=A$+"Up:            ; "
        A$=A$+"    Move 0,-10,2    ; "
        A$=A$+"    Jump Start     ; "
        A$=A$+"Down:           ; "
        A$=A$+"    Move 0,10,2     ; "
        A$=A$+"    Jump Start     ; "
        `
        For LOP=1 To 15
          Bob LOP,Rnd(150),Rnd(100),1
          Channel LOP To Bob LOP
          Amal LOP,A$
        Next LOP
        `
        Wait Vbl

Amal On
        `
        Direct

OK, so you don`t want to structure your AMAL programs, you could shorten them
by just using the UPPERCASE characters. Just look at the following AMAL string.
If you value your sanity, don`t try to type it in!

        A$="S:P;LR0=J1;"
        A$=A$+"IR0&8JR;"
        A$=A$+"IR0&4JL;"
        A$=A$+"IR0&1JU;"
        A$=A$+"IR0&2JD; "
        A$=A$+"JS;"
        A$=A$+"R:;"
        A$=A$+"M10,0,2;"
        A$=A$+"JS;"
        A$=A$+"L:;"
        A$=A$+"M-10,0,2;"
        A$=A$+"JS;"
        A$=A$+"U:;"
        A$=A$+"M0,-10,2;"
        A$=A$+"JS;"
        A$=A$+"D:;"
        A$=A$+"M0,10,2;"
        A$=A$+"JS;"

Having fun` I hope so! The final part of this exciting instalment gives us an
AMAL-controlled player and baddie:

        Load "GAME_SPRITES.ABK"
        Screen Open 0,320,200,16,Lowres
        Curs Off
        Flash Off
        Cls 0
        Get Sprite Palette
        Double Buffer
        Autoback 0
        Bob 1,150,100,1
        Bob 2,20,20,2

The string A$ is exactly the same as in the first program except that the
horizontal and vertical positions of the player are fed into the external
registers RA and RB. These are then read inside the baddie control program
stored in B$ to make that the evil beastie tracks us down!

        A$="  Start: Pause ; Let R0=J1  ; "
        A$=A$+"    Let RA=X ; Let RB=Y ; "
        A$=A$+"    If R0&8 Jump Right ; "
        A$=A$+"    If R0&4 Jump Left  ; "
        A$=A$+"    If R0&1 Jump Up   ; "
        A$=A$+"    If R0&2 Jump Down  : "
        A$=A$+"    Jump Start     ; "
        A$=A$+"Right:           ; "
        A$=A$+"    Move 10,0,2     ; "
        A$=A$+"    Jump Start     ; "
        A$=A$+"Left:           ; "
        A$=A$+"    Move -10,0,2     ; "
        A$=A$+"    Jump Start      ; "
        A$=A$+"Up:             ; "
        A$=A$+"    Move 0,-10,2     ; "
        A$=A$+"    Jump Start      ; "
        A$=A$+"Down:            ; "
        A$=A$+"    Move 0,10,2      ; "
        A$=A$+"    Jump Start      ; "
        `
        B$=B$+"Start: Pause        ; "
        B$=B$+"    If X>RA Jump Right ; "
        B$=B$+"    If X<RA Jump Left  ; "
        B$=B$+"    If Y>RB Jump Up   ; "
        B$=B$+"    If X<RB Jump Down  ; "
        B$=B$+"    Jump Start     ; "
        B$=B$+"Right:           ; "
        B$=B$+"    Move 10,0,2     ; "
        B$=B$+"    Jump Start     ; "
        B$=B$+"Left:           ; "
        B$=B$+"    Move -10,0,2    ; "
        B$=B$+"    Jump Start     ; "
        B$=B$+"Up:            ; "
        B$=B$+"    Move 0,-10,2    ; "
        B$=B$+"    Jump Start     ; "
        B$=B$+"Down:           ; "
        B$=B$+"    Move 0,10,2     ; "
        B$=B$+"    Jump Start     ; "
        `
        Channel 1 To Bob 1
        Amal 1,A$
        Channel 2 To Bob 2
        Amal 2,B$
        Amal On 1
        Wait Vbl
        Amal On 2
        `
        Repeat
          Inc SCORE
        Until Bob Col(1)
        Boom
        Print "YOU ARE DEAD!!!! YOUR SCORE IS";SCORE
        Update

That brings us to the end of a very practical column!


Issue 49 ­ June 1992
` Creating wonderful worlds and "alternate realities" with your Amiga's 4,096
colours

Your Amiga is blessed with a wonderful collection of 4,096 different colours.
With these colours we can create new worlds and alternate realities with art
packages like Deluxe Paint. With Amos we can go a step further and use the
power of colour to produce animation.

Before we go into too much detail, it will help for you to know a little bit
about the way colours are handled by the Amiga. Under ordinary circumstances
you can display 32 individual colours on-screen. These are stored in colour
registers. You can think of a colour register as being an empty paint pot,
which we can fill up with any colour.

At its simplest form you can see colour cycling at fairgrounds and fancy
Christmas displays. This happens when  a string of unlit bulbs are switched on
in sequence one at a time. This gives the illusion that a bulb is moving along.
We can demonstrate this with a simple program.

The first step is to open up our screen, so go into the Amos editor and type:

        Screen Open 0,320,200,16,Lowres
        Flash Off
        Cl 0
        Curs Off

Now we must set up our palette. Remember that each of the numbers in the
following line represent the "paint" that we are pouring into the paint pot
(colour register).

The colour which we have poured into colour register number one ­ remember that
the 32 different colour registers are labelled from 0 to 31 ­ is white ($FFF)
and represents our bulb which is switched on:

        Palette
        $0,$FFF,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,

Now we must draw our lightbulbs. Each one will use a different colour, selected
with the PEN command:

        Paper 0
        For LOP=1 To 15
         Pen LOP
         Wait Vbl
         Print "0";
        Next LOP

The final stage is to start the colour cycling up. We will do this using the
Shift command, which uses four parameters. The first is the speed at which the
colours will cycle, the second and third specify the start and end colour
registers which will be cycled and the final parameter is for special effects -
which we will not be using!

Just how does it work? Well, the Shift command will move the colour stored in
register number 1 into register number 2, the colour in register 2 into
register 3, 3 into 4, 4 into 5 etc. It's a bit like pouring the paint from one
pot into another!

        Shift Up 2,1,15,1
        Direct

That's it. Simple, huh?

Another interesting use of colour cycling is to produce weird backgrounds for
games and demos ­ or hypnotising friends and relatives!

In the next example we will draw a small block 16 x 16 pixels in size, grab it

as a Bob and finally paste it all over the screen. Once again, our screen must
be opened up, and a palette selected. In this case I have used shades of blue:

        Screen Open 0,320,200,16,Lowres
        Flash Off
        Cls 0
        Palette $0,$5,$6,$8,$9,$B,$C,$E,$F

Now we will read in the data ­ sorry, but there is quite a lot of it! ­ and
draw it onto the screen:

        For Y=0 To 15
         For X=0 To 15
          Read SPOT
           Ink SPOT
          Plot X,Y
         Next X
        Next Y

By using the Get Bob command we can grab this small block and stick it all over
the screen, 20 blocks across and 12 blocks down:

        Get Bob 1,0,0 To 16,16
        For Y=0 To 11
         For X=0 To 19
          Paste Bob X*16,Y*16,1
         Next X
        Next Y

We must now start that funky colour cycling! This time we will be cycling
colours 1 to eight:

 Shift Up 4,1,8,1
 End
 Data $1,$1,$1,$1,$1,$1,$1,$1,$1,$2,$3,$4,$5,$6,$7,$8
 Data $1,$2,$2,$2,$2,$2,$2,$2,$1,$2,$3,$4,$5,$6,$7,$7
 Data $1,$2,$3,$3,$3,$3,$3,$1,$2,$3,$4,$5,$6,$6,$6,$6
 Data $1,$2,$3,$4,$4,$4,$4,$4,$1,$2,$3,$4,$5,$5,$5,$5
 Data $1,$2,$3,$4,$5,$5,$5,$5,$1,$2,$3,$4,$4,$4,$4,$4
 Data $1,$2,$3,$4,$5,$6,$6,$6,$1,$2,$3,$3,$3,$3,$3,$3
 Data $1,$2,$3,$4,$5,$6,$7,$7,$1,$2,$2,$2,$2,$2,$2,$2
 Data $1,$2,$3,$4,$5,$6,$7,$8,$1,$1,$1,$1,$1,$1,$1,$1
 Data $1,$1,$1,$1,$1,$1,$1,$1,$8,$7,$6,$5,$4,$3,$2,$1
 Data $2,$2,$2,$2,$2,$2,$2,$1,$7,$7,$6,$5,$4,$3,$2,$1
 Data $3,$3,$3,$3,$3,$3,$2,$1,$6,$6,$6,$5,$4,$3,$2,$1
 Data $4,$4,$4,$4,$4,$3,$2,$1,$5,$5,$5,$5,$4,$3,$2,$1
 Data $5,$5,$5,$5,$4,$3,$2,$1,$4,$4,$4,$4,$4,$3,$2,$1
 Data $6,$6,$6,$5,$4,$3,$2,$1,$3,$3,$3,$3,$3,$3,$2,$1
 Data $7,$7,$6,$5,$4,$3,$2,$1,$2,$2,$2,$2,$2,$2,$2,$1
 Data $8,$7,$6,$5,$4,$3,$2,$1,$1,$1,$1,$1,$1,$1,$1,$1

Have fun with colour cycling and send in any examples that you come up with.

We have seen how to create a simple Pacman-type game in Amos, but what's next?
How about education! An absolute wealth of educational software has appeared in
shops and in public domain catalogues since the release of Amos.

Many people who have good ideas but have been unable to implement them into
traditional languages ­ like Amiga Basic ­ have found that Amos allows them to
breathe life into their ideas.


Issue 50 ­ July 1992
` Producing smooth and fast scrolls for use in games

Many people bought Amos in the belief that it would let them make fantastic
software with ease, save the universe as we know it and make the perfect cup of
coffee.

Unfortunately life is never that simple and to get any satisfaction from using
this language you will have to get to know your Amiga and its capabilities a
little better. It also helps to have good Colombian beans.

There are two main methods of producing scrolling screens. The first is to take
a series of interconnecting picture blocks, put one on the screen, move it a
bit and then place the next section.


This is known as a software scroll because it is up to us ­ the programmers ­
to do all of the hard work. Xenon II uses this type of scrolling. One of the
advantages of software scrolling is that it requires very little memory,
because you really only have to have a standard sized screen open which is 320
x 200 pixels in size.

A hardware scroll is something which is handled mainly by the Amiga's custom
chips, which are known as hardware. It is produced by defining a big picture,
looking at one section of the picture and then panning across the rest, just
like a television looking at a wall-mounted mural. Kick Off uses this type of
scrolling.

Although fast, hardware scrolling eats up lots of memory. Fortunately, the ease
with which we can manipulate a hardware scroll more than makes up for the
memory consumption. Before we do this I think we should look at how versatile
the Amiga's screen system really is.

Amiga screens are something special. You need to imagine them not as literal
pictures but as a window looking into your machine's memory. By moving our
viewpoint around we can examine almost any part of the chip memory contained
inside the Amiga. Incidentally, this is how many graphics "grabbers" work.

Amos allows us to manipulate these "windows on the world" using Screen Display
and Screen Offset commands. Screen Offset controls our view of the computer's
memory through our window, while Screen Display controls the size of this
window and its position on the monitor.

OK, now we all know how to open a screen inside Amos, don't we? It's pretty
simple ­ load Amos and make sure you are inside the editor (not Direct Mode).
Type this line in:

        Screen Open 0,320,200,16,Lowres

This tells Amos to create screen number 0 with a horizontal resolution of 320
pixels, a vertical resolution of 200 pixels and 16 colours in lo-res mode,
which means the pixels are pretty square and chunky. We now have a screen we
can experiment with.

The next step is to define two variables XSIZE and YSIZE ­ these will tell Amos
how big our window will be:

        XSIZE=320
        YSIZE=200

OK, now we must start a loop which will allow us to change the characteristics
of this window with the mouse buttons. Every time we go around the loop, the
mouse co-ordinates are put into the variables X and Y.

These are then used to position the window on your monitor. It sounds
confusing, but if you imagine the window as a piece of paper being moved around
the desk ­ which is your monitor! ­ it may sound a little clearer:

        Repeat
        X=X Mouse-100
        Y=Y Mouse-160

Now we must check the state of the mouse keys. If the left button is pressed
the variable XSIZE is decremented. If the right button is pressed the variable
YSIZE is decremented. The command ADD allows a little more control over
variables than the standard INC or DEC commands. By using ADD we can make the
number contained in XSIZE wrap from 0 to 320 with very little work:

        If Mouse Key=1
                Add XSIZE,-1,1 To 320
        End If
        If Mouse Key=2
                Add YSIZE,-1,1 To 200
        End If

OK, now for the magic command. As you can see the first parameter is the screen
number., followed by the X and Y positions plus XSIZE and YSIZE:

        Screen Display 0,X,Y,XSIZE,YSIZE

The final part of our program waits for you to press both mouse keys before it
stops:

        Until Mouse Key=3
        End

I hope this has not been too complicated to follow so far. The concepts are
simple, but I must admit that the whole subject can become overpowering!

I have now introduced you to the basics of using Screen Display, but what about
Screen Offset? It is this command which actually creates the scrolling. If we
designed a standard screen size and used Screen Offset to look above ­ or below
­ it, we would see what is contained in those portions of memory.

To start off with, let's open up our screen by typing the following lines into
the Amos editor (remember to Save your last program if you want to keep it):

        Screen Open 0,320,200,4,Lowres
        Flash Off
        Hide On
        Curs Off
        Palette $0,$90
        Cls 1

You will notice that I have reduced the amount of colours from the standard 16
down to four. I have also increased the size of the screen to 600 pixels high,
which is three times the height of a normal screen.

The next Screen Display command features four commas in succession. This is not
a typing error! It tells Amos to use its own defaults instead of the missing
parameters. The last part of the line tells Amos that we only want to display
200 lines of the 600 line screen:

        Screen Display 0,,,,200

I am not a great lover of football ­ or football simulation computer games ­
but they can be useful to demonstrate the principles we are dealing with here.
So in the best tradition of Blue Peter, here is a pitch I drew earlier:

        Draw 0,299 To 320,299
        Box 0,0 To 319,599
        Circle 160,299,105

Even though we cannot see the whole screen, Amos will draw it for us. Neat,
huh? The penultimate step in this program is to let Amos know which part of the
600-line screen we wish to display inside our small 200-line window. Once
again, the Screen Offset command contains a couple of commas, which tells Amos
to use the default value for the X position of our view:

        YPOS=0
        Screen Offset 0,,YPOS

Now for the exciting bit! By pressing the left mouse button the screen will
scroll smoothly upwards by telling Amos ­ through the Screen Offset command ­
to look at a different part of the picture held in memory through our small
screen or "window". If we press the right button the screen will scroll
downward:

        Repeat
                If Mouse Key=1 and YPOS.0
                        Add YPOS,-5
                        Screen Offset 0,,YPOS
                End If
                If Mouse Key=2 and YPOS,400
                        Add YPOS,5
                        Screen Offset 0,,YPOS
                End If

We must put a WAIT VBL command here to tell Amos to slow down. Try removing it
to see how fast the program runs!

        Wait Vbl
        Until Mousekey=3

Why not experiment and see what you come up with?


Issue 51 ­ August 1992
` Generating Amiga windows and menus

If you are coding something other than a game, you`ll have to get used to
generating Amiga windows and menus. This is much easier in Amos than it is in,
say, AmigaBasic, where you have to specify everything so precisely you might as
well draw it on the screen with a Biro.

Getting a screen together is easy enough with the Screen Open command, but what
do you have to do to make the screen and its windows act like a normal Amiga
program` I`ve been doing a lot of this sort of thing lately, so try this
listing for size:

        Screen Open 0,640,256,16,Hires

Nice and simple to start with. Just a med-res screen to give you that utility
look. Now we define our menus:

        MenuS(1)=` Project     `
        MenuS(1,1)=` Load     `
        MenuS(1,2)=` Load As...     `
        MenuS(1,3)=` Save     `
        MenuS(1,4)=` Save As...     `

That`s menu 1 sorted and as you can see it`s a very simple procedure to name
the menus, with 1 being the menu title, and 1,1 being a submenu. We do the same
for the next menu, but with a little twist:

        MenuS(2)=` CyberSpace     `
        MenuS(2,1)=` Engage!     `
        MenuS(2,1,1)=` Are you sure`     `
        MenuS(2,1,1,1)=` Yes - GO!!     `
        MenuS(2,1,1,2)=` No - Abort     `
        MenuS(2,2)=` Morph     `
        MenuS(2,3)=` ID scan     `
        MenuS(2,4)=` Alter ID     `

You can go on adding submenus like 2,1,1,1,1,1 to infinity, but bear in mind
that anything other than one or two submenus really gets on the operators?
nerves after a very short while. Finally we turn the menus on:

        Menu On

and at this point the menus are active. You can of course turn them off later
if you don`t want anyone using the menus at a certain point in the program.
Finally, for the benefit of our listing, a few cosmetic and diagnostic details:

        Curs Off : Cls O
        Do
        Print `Menu= `;Choice(1);`
        Selection= `;Choice(2)
        Loop

You can now run the program. Notice how the menu and selection numbers change
when you select a different menu item. This is how you know what the user has
selected, and it`s simply that.

Find out what choice 1 and 2 are and you know what menu item was under the
pointer when the user let go of the RMB. But to really get to grips with the
menus, especially if you have a number of them, you have to use the Amos auto
menuing system within Menu On. This takes a little bit of practice, but it`s
really quite simple. The revised program starts the same, pretty much:

        Screen Open 0,640,256,16,Hires
        Cls 0 : Curs Off
        MenuS(1)=`Project     `
        MenuS(1,1)=`Load     `
        MenuS(1,2)=`Load As...     `
        MenuS(1,3)=`Save     `
        MenuS(1,4)=`Save As...     `
        MenuS(2)=`CyberSpace     `
        MenuS(2,1)=`Engage!     `
        MenuS(2,1,1)=`Are you sure`     `
        MenuS(2,1,1,1)=`Yes - GO!!     `
        MenuS(2,1,1,2)=`No - Abort     `
        MenuS(2,2)=`Morph     `
        MenuS(2,3)=`ID scan     `
        MenuS(2,4)=`Alter ID     `

But at this point it diverts into new territory:

        On Menu Proc PROJECT,CYBER
        On Menu On
        Menu On
        Wait Key

This turns on the auto menuing system and waits for you to either make a
selection from the menus or press a key on the keyboard. The PROCs you
mentioned in the ON MENU ON statement are then defined somewhere else in the
program, like right now for example:

        LISTINGS MACRO2 Procedure PROJECT
        Cls
        Y=Choice(2)
        Locate 0,22 : Print `Menu: Project`
        Locate 0,23
        If Y=1 Then Print `Load what``
        If Y=2 Then Print `Load as what``
        If Y=3 Then Print `Save what``
        If Y=4 Then Print `Save as what``
        OM
        End Proc
        Procedure CYBER
        Cls
        Y=Choice(2)
        Locate 0,22 : Print `Menu: Cyberspace`
        Locate 0,23
        If Y=1 Then Print `Yes Or No` Which is it``
        If Y=2 Then Print `Morph yourself`
        If Y=3 Then Print `Okay you`re scanned`
        If Y=4 Then Print `You can`t change ID`
        OM
        End Proc
        End
        Procedure OM
        On Menu On
        End Proc

And there you have it. The responses are put into PROCs and this makes the
whole thing a lot simpler. You only have to scan for one variable CHOICE(2) as
the first one, the menu itself is chosen for you automatically, and you`re sent
right to the PROC that deals with that menu.

Once you`ve got subroutines accepting input from menus, you`ve got yourself the
basis for a mighty fine menu driven utility program.


Issue 52 ­ September 1992
` Altering text font, colour and sizes

Text in computer programs is something you take for granted. I know I do, and
it`s hard to think beyond the kind of things that have been possible in
AmigaBasic, which is what most people`s programming experience consists of pre-
Amos.

But Amos opens up new vistas of programming, and simply too. This month we`ll
be looking at how you can spice up your text, whether it be a game logo, high
score table, or just the title screen of your new business program.

Text in a computer program tells you two things. The words on the screen tell
you what to do, and the style with which they do it tells you a lot about the
programmer`s attention to detail.

Normal text tricks include clever formatting and changes of colour. But more
impressive are changes of font and size. It`s like the difference between
typing on a typewriter and making up your text in a DTP program.

Firstly if you don`t want to faff about with fonts, make your titles a
different colour with Pen and centre them with Centre. But there are two kinds
of text in Amos - normal text and what they call `graphic text`. Normal text is
printed to the screen with a Print statement, but graphic text needs to be put
to the screen using Text, like so:

        Rem * Simple Font Prog 1 *
        Get Fonts
        Paper 8
        Set Font 8
        Ink 2 : Text 5,50, `Amiga Computing`

The Get Fonts command scans the ROM and Fonts: directory on disk for fonts, and

Set Font sets  the font to be printed to the appropriate font in the pecking
order.

The colour of graphic fonts is set using the Ink command rather than Pen
(they`re drawn rather than printed, being graphics!). Once you have graphic
text under control you can do all manner of technical tricks like putting
shadows under the text

        Rem Totally Fontastic!
        Rem
        Paper 8 : Curs Off : Hide : Cls
        Get Fonts
        For F=1 To 30
        If Font$(F)
        Clw
        Print Font$(F)
        Set Font F
        For Y=20 To 150 Step 20
        SHAD[10,Y, `Amiga Computing`,1]
        Next
        Wait Key
        End If
        Next
        Procedure SHAD[X,Y,A$,D]
        Gr Writing 0
        Ink 0
        For DX=-D To D
        Text X+DX, Y-D,A$ : Text X+DX, Y+D,A$
        Next
        For DY=-D+1 To D-1
        Text X-D, Y+DY,A$ : Text X+D,Y+DY,A$
        Next
        Ink 2 : Text X,Y,A$
        End Proc

using JAM1 mode via the GR WRITING command to ensure a good impression. Or if
you`re particularly clever you can even add a drop shadow using the same
program but simply changing the last two lines:

        Ink 2 : Text X-2,Y-2,A$
        End Proc

This offsets the final white printing of the characters up and to the left of
the black outline, creating a drop shadow. Experiment with the code and see how
many effects you can do. How about making the last print in the same Ink as the
Paper colours for an outline font`

More exotic effects can be obtained using Aaron Fothergill`s CText program, in
which graphic text is taken to its extreme. If you get this program (either
from Aaron's Amos Club or Déjà Vu Software) you can create a font in Deluxe
Paint and include it in your program just like the pros do.

The font is stored on an IFF picture file like the example screen on this page,
and then scanned into CText a letter at a time. Then you can print it to the
screen in the same way you would ordinary text, or even do a scrolly message
across another screen.

Finally, Rainbow text is easy, and very effective. Basically what you have is a
rainbow you set up using the copper, and the text is like a lot of holes
punched through a screen covering the rainbow, giving you rainbow coloured
text! Try this listing to give you a taster:

        Rem * RainbowText.Amos *
        Rem
        Cls 0 : Curs Off : Hide
        Gosub STRIPES
        For X=0 To 23
        Pen 1 : Paper 0 : Print `Rainbow Text!!!
        Rainbow Text!!!`
        Next X
        Wait Key
        `
        STRIPES:
        Set Rainbow 0,1,280,??,??,??
        Rainbow 0,0,0,280
        Colour Back 0
        Restore RDATA
        For C=0 To 279 : Read CVA : Rain(0,C)=CVA
        Next C : View
        Return
        RDATA:
        Data $0,$0,$0,$111,$222,$333,$444,$555
        Data $666,$777,$888,$999,$AAA,$BBB,$CCC,$DDD
        Data $EEE,$FFF,$FFF,$EEE,$DDD,$CCC,$BBB,$AAA
        Data $999,$888,$777,$666,$555,$444,$333,$222
        Data $300,$200,$300,$400,$500,$600,$700,$800
        Data $900, $A00,$B00,$C00,$D00,$E00,$F00,$F00
        Data $E00,$D00,$C00,$B00,$A00,$900,$800,$700
        Data $600,$500,$400,$300,$200,$20,$30,$40
        Data $50,$60,$70,$80,$90,$A0,$B0,$C0
        Data $D0,$E0,$F0,$F0,$E0,$D0,$C0,$B0
        Data $A0,$90,$80,$70,$60,$50,$40,$30
        Data $30,$0,$1,$2,$3,$4,$5,$6
        Data $7,$8,$9,$A,$B,$C,$D,$E
        Data $F,$F,$E,$D,$C,$B,$A,$9
        Data $8,$7,$6,$5,$4,$3,$2,$1
        Data $0,$0,$22,$33,$44,$55,$66,$77
        Data $88,$99,$AA,$BB,$CC,$DD,$EE,$FF
        Data $FF,$EE,$DD,$CC,$BB,$AA,$99,$88
        Data $77,$66,$55,$44,$33,$22,£110,$220
        Data $330,$440,$550,$660,$770,$880,$990,$AA0
        Data $BB0,$CC0,$DD0,$EE0,$FF0,$FF0,$EE0,$DD0
        Data $CC0,$BB0,$AA0,$990,$880,$770,$660,$550
        Data $440,$330,$220,$101,$202,$303,$404,$505
        Data $606,$707,$808,$909,$A0A,$B0B,$C0C,$D0D
        Data $E0E,$F0F,$F0F,$E0E,$D0D,$C0C,$B0B,$A0A
        Data $909,$808,$707,$606,$505,$404,$303,$202
        Data $111,$222,$333,$444,$555,$666,$777,$888
        Data $999,$AAA,$BBB,$CCC,$DDD,$EEE,$FFF,$FFF
        Data $EEE,$DDD,$CCC,$BBB,$AAA,$999,$888,$777
        Data $666,$555,$444,$333,$222,$300,$200,$300
        Data $400,$500,$600,$700,$800,$900,$A00,$B00
        Data $C00,$D00,$E00,$F00,$F00,$E00,$D00,$C00
        Data $B00,$A00,$900,$800,$700,$600,$500,$400
        Data $300,$200,$20,$30,$40,$50,$60,$70
        Data $80,$90,$A0,$B0,$C0,$D0,$E0,$F0
        Data $F0,$0,$0,$0,$0,$0,$0,$0

Phew! Sorry about all that data, but it`s needed to give you the rainbow
stripes. And there you see it, rainbow text. Now let them try and ignore that
screen!


Issue 53 ­ October 1992
` Using Amos to improve your computer's sound

One of the key things which distinguishes Amos from other types of Basic is its
grip on the Amiga`s breathtaking sound playing capability. But then again the
whole idea of Amos is the be able to access all the functions of the Amiga
rapidly and easily, using one command where previously only a few hundred would
do.

The Amiga can grab and play sampled sounds very easily. The sound chip can be
used, and samples can be put into a bank for you to use in your own programs.
Amos can also play music, like the ABK files on your demo disks. But for now
let`s talk about samples. Using sampled sounds is easy, and similar to the use
of IFF picture files, in as much as you can load them in off disk as they are
or use them from a bank.

You need an Amos program called Sam Maker, and this allows you to load samples
and put them together into a bank in memory. The problem with loading samples
from disk is that you have to BLOAD them and specify locations in memory and
all that, which is a little bit technical and not to say a touch heavy on
memory and resources.

It`s a far more elegant solution to store them in a bank as they are ready to
access at any time during your program, and they are loaded instantly. Once you
have your samples in a bank you can play them back at any speed, which changes
the time the sample takes to play and thus the pitch of the sample.

So you can either have samples of speech, snatches of music, or even single
notes of an instrument which you can play in a sound/noise/Pro Tracker-type
program at different pitches. Playing samples in Amos is a matter of using the
Sam Play command:

        Sam Play VOICE,SAMPLE,FREQUENCY

The voices your sample will use are set by setting a bit in V, like so:

        %1000 voice 3
        %1010 voice 3 and 2
        %1111 voices 3, 2, 1 and 0

This is all very well documented, but here`s an idea for you. The Amiga has
four voices, and these are paired to play in either left or right stereo
channel. Voices 0 and 3 play through the left speaker and 1 and 2 play through
the right.

It struck me the other day that it would be easy to take advantage of this
stereo capability and make stereo sounds - true stereo sounds, not just one
sound in one ear and another in the other ear like most programs you hear/see.

If you want to pan a sound around in the stereo spectrum you have to alter the
volume across the two stereo channels of the same sound. This is called mixing
or panning in the trade.

To clarify that, a sound appears in a certain position in the stereo `picture`,
an imaginary 3D space with a left, right, in and out, depending on how quiet or
loud it is in each ear. A noise which is soft in the left ear and loud in the
right will appear to come from right of centre in front of the listener.

So in order to simulate stereo panning in an Amiga sound, all you have to do is
put the same sound in both speakers and alter the volume of one or the other to
move the sound in space! Let`s try this out. Have your Amos Data disk in one of
your drives  and run the following program:

        Screen Open 0,640,256,16,Hires
        Hide : Curs Off : Paper 0 : Cls 0
        Load `Amos_Data:samples/samples.abk`

After all the usual setup, we load in some samples from the Amos Data disk. If
you don`t have this in the drive it`ll prompt you, because I`ve specified the
exact disk name in the Load statement:

        Sam Loop On
        Volume %10,0 : Volume %1,50

Then we turn Sam Loop On to make the sound continuous, and so make it easier to
hear the stereo panning. Next we set up the initial volumes of the two voices
we`ll be using, in this case voices 1 and 2, indicated by the binary codes
%0010 and %0001. This sets the volume so that the right channel is silent and
the left is set at 50:

        X=1
        Locate ,5 : Pen 4 : Centre `AC brings you *Stereo Panning*`
        Locate ,7 : Centre `The sound moves slowly from left to right`

Next we have the main program loop. The PANME procedure increments the right
and decrements the left at half second intervals until the sound has travelled
fully from left to right:

        Do
        Sam Play %11,3
        PANME
        Loop
        `
        Procedure PANME
        P1=0 : P2=50
        Repeat
        Volume %10,P1 : Volume %1,P2
        Wait 25
        Inc P1 : Dec P2
        Until P1=50
        End Proc

As they say in all the old Bond movies, crude but effective. If you were very
clever you could even have another sound panning the other way too.

Or even, and this is a really nice one, move the sound in stereo according to
movements from the joystick, which also moves the sprite that the sound relates
to! This would give you a real stereo effect for very little programming.

Simply put, this would involve the use of a simple test for the joystick
direction as another procedure at the end of the program, and putting the proc
name in the main loop. This routine gives you an idea of what I`m talking
about:

        Screen Open 0,640,256,16,Hires
        Hide : Curs Off : Paper 0 : Cls 0
        Load `Amos_Data:samples/samples.abk`
        Volume %10,25 : Volume %1,25
        P1=25 : P2=25
        Do
        Sam Play %11,3
        If Jleft(1) Then Inc P1 : Dec P2
        If Jright(1) Then Inc P2 : Dec P1
        If P1...
        If P2...
        Volume %10,P1 : Volume %1,P2
        Wait 25
        Locate 0,0 : Print P1,P2
        Loop

Once again it uses the samples from Amos_Data, but this time the sound pans in
stereo depending on whether you move the stick left or right. The location of
the sound is shown at the top of the screen.

Try that out at home this month, and try to make it faster still if you can.
Also, you can add a facility to pan the sound in and out as well as from left
to right, and move a sprite at the same time.


Issue 54 ­ November 1992
` Manipulating and filling screens with all sorts of stuff

Although you may already know this, Amos has some very powerful commands for
the manipulation of screens and their contents. You will know by now how to
load and define screens, sure, even if you`ve only just bought the program.

What about moving screens around once you have them defined and loaded` Amos
has a number of very useful (I love understatement, don`t you?) commands for
manipulating screens, and these are easy to spot as they usually have the word
`screen` in them.

Screen Hide will take a screen you`ve loaded and send it away somewhere until
it is needed. To show it again you just need to use the Screen Show command.
Logical really, and as always in Amos Show and Hide are the exact opposite when
applied to what you might call visual commands.

The best place to hide an Amos screen of course is in a SPACKed memory bank and
a Packed Picture, as it takes up less memory. Screen Copy is used as a part of
the process of scrolling all or part of screens, in combination with Def
Scroll, Scroll and Screen Swap, as we see in this example:

        Load Iff `name your path and picture here`,1
        Screen Open 0,320,256,32,Lowres
        Get Palette 1 : Curs Off : Flash Off

This is all the usual setup guff, and if you`ve got any sense you`ll stick this
away as a file to merge to save you typing in all this before you begin. The
file you choose is loaded into screen 1, which at the moment is invisible:

        Screen Copy 1 To 0 : Screen 0 : Double Buffer : Bob Update
Off

You`ve opened a screen 0 and you`re copying screen 1 to 0, then making the
system show screen 0. Double buffering makes things nice and smooth by hiding
any loading of images:

        S=2
        Def Scroll 1,80,80 To 240,240,0,-S

S is the increment of the scroll, and the Def Scroll routine defines the area
of the scroll using the usual co-ordinates. Next you need to set up a loop and
feed the increments to it:

        Repeat
        For Y=0 To 199 Step S
        Scroll 1
        Screen Copy`` 1,80,Y,240,Y+S To 0,80,240-S
        Screen Swap
        Screen Copy 1,80,Y,240,Y+S To 0,80,240-S
        Wait Vbl
        Next Y
        Screen Swap : Wait Vbl : Scroll 1
        Until Mouse Key

So the area defined by the Def Scroll statement is scrolled upwards using the
Repeat Until loop. This is done over and over until any mouse button is
pressed, at which time the program stops. Choose a picture which has some
colours and shapes on it. If the picture is too plain you won`t really see the
effect.

Screen swap uses an `invisible` screen called the `logical screen` on which it
renders things like scrolls, like in our example. When the object or screen has
been modified, the results are copied to the real screen.

Logical screens are very useful for smoothing otherwise slow or clunky
rendering routines. Try the last example and alter the settings to see how it
changes when you adapt certain parts of the program, particularly the Def
Scroll and Screen Copy lines.

Now then, this is when it starts to get really interesting. In the Amiga`s
display system, a dual playfield is where two Amiga screens are visible at the
same time, overlaid one on the other, where one is visible through the other.

This is a handy effect for what they call in the game reviewing business
`parallax scrolling`, like in the game Shadow of the Beast. There is a good
Amos demo which parodies this effect, called Madness Week by the famous French
Amos hacker Syntex. Get it from the Amos PD Library, and you`ll see what I
mean.

` Your letters
Paul Jermany writes: `Why is it that when I design a sprite using the Amos
Sprite Editor, for example a red apple, it appears blue on the screen, although
when I use the Bob command it appears as it should` I phoned the Amos help line
and they suggested the following:

        For 1=0 To 15
        C=Colour(1)
        Colour 16+1,C
        Next 1

At last I can get my sprites on the screen in their true colours, but the
program failed. Is it something I`m doing wrong`? You didn`t mention Paul if
you were using the Get Sprite Palette command. Are you` Of course you are. One
reason for the problem is that Bobs use the screen palette and the sprites use
the next 16 colours along, which is what your little proggy from Europress was
all about.

The thing is that the Amos Sprite Editor is in fact a Bob editor, which is why
if you load the objects as sprites you will get goofy colours. So use the Bob
commands and have done with it, that`s my advice to you. The speed difference
is minimal and the benefits of Bobs over sprites is worth it. Sprites are
hardware limited, and Bobs are no limits but slightly slower. I know which I
prefer.


Issue 55 ­ December 1992
` Sprites and Bobs and how to move them around the screen

Almost every text written about Amos bangs on for quite some time about sprites
and Bobs, and now it`s my turn.. Of course, one of the things which makes Amos
so brilliant is its ability to slap objects on the screen and whizz them about
as fast as you like. Normal Basic just doesn`t cut it.

There are Bobs and there are sprites. Sprites are limited in size, and their
palette can only be the last 16 colours of a 32 colour display. So if the
sprite`s palette takes some of its colours from the first 16, those colours
will change with different backgrounds.

Great care is needed in the creation of sprites. Bobs make use of the blitter
chip in the Amiga, capable of copying images to the screen at rates close to a
million pixels per second. Bobs are just like sprites, but instead of being
limited in amount for size, they`re unlimited. They can have any colours and
resolutions, and you can use as you like on-screen.

Obviously the more Bobs you have on screen the more stress you put on memory
and processing time, but don`t worry about that. Bear in mind, though, that
Bobs are slower than sprites and use up more memory. As a rule of thumb, use
Bobs for slow moving and big shapes, and use sprites for fast moving small
shapes - that`s a fair division of labour. One other thing is that sprites can
be made to be bigger than the limit of 16 pixels, by using what they call in
Amos `computed sprites`.

The computer automatically sticks sprites together to make bigger sprites. You
can only have up to 128 pixels in width, as there are only eight hardware
sprites. The biggest mistake people make when using sprites or Bobs is to
instantly use AMAL when in fact they are going to compile the program anyway.

The sprite and Bob commands in Amos are so flexible you can ignore it except
for the most mundane tasks, and then once you`ve compiled the program, provided
your code is reasonably sensible and well ordered that is, the sprite will
whizz around like nobody`s business.

Once you`ve mastered the basics of sprite movement, which should take you about
ten minutes to suss, you face the prospect of all manner of objects whizzing
about missing each other and providing no information about their position or
any entertainment value whatsoever. Which is where this month`s program comes
in.

Obviously the sprites are from the excellent Sprite 600 set, available from
your Amos disks or via one of the various Amos PD outlets. In this example, the
spaceship meekly waits at the end of the screen, and you can`t move it at all.
The alien ship comes from the right of the screen, and when the ship is touched
by the alien it explodes beautifully. First, all the usual setup stuff:

        Screen Open 0,320,200,16,Lowres
        Curs Off : Flash Off : Hide : Cls 0

OK, so far so good. All the image information for the explosions etc are in the
sprite files, and like other examples which use the example sprite files, the
sprites are loaded one after the other into the same sprite bank.

        Load `df0:sprite_600/aliens/alien1.abk`
        Load `df0:sprite_600/space/ship3.abk`,1

If you wanted to make this program a little bit easier to handle - and cut out
the wait for the sprites to load from disk - you should load them in direct
mode and save them off with the program.

To be really kind you could load the sprite files into the bank, merging them
by adding the positive number to the end of the filename, and then save off the
bank to disk as a new ABK file.

        Get Sprite Palette
        Double Buffer

Once we have loaded the sprites we`ve set up DOUBLE BUFFER to prevent any
flickering of the sprites, and GET SPRITE PALETTE will make sure our sprites
are the same colours as they should be.

In this case, the sprites are from the same set so they are all the same
colours. If your sprites are of different palettes, you may have to re-edit
them and alter the palettes to fit.

        Bob 1,0,80
        Bob 2,320,80
        Shared M
        M=320

Next we set up the initial positions of the Bobs, and then define a variable as
shared for the position of the Bob in the proc called _ALIENMOVE. The reason
this variable is shared is that the proc is called each time the Bob is moved,
and so the variable has to be defined outside the Proc.

If the variable isn`t shared then it is always 0, as it never gets defined
according to the Proc. In this case this means that the sprite would suddenly
turn up in the same position as the ship and explode the ship right away,
rather than travelling gently across the screen. It`s an early bug in this
routine, which is how come I know about it! Next we loop.

        Do
        _SHIPANIM
        _ALIENMOVE
        If Bob Col(1) Then _YOURDEAD
        Loop

The main loop of the program is the DO LOOP, which will go on forever until the
Ctrl-C combo is pressed. The loop runs through the main parts of the program,
calling procs and then looping back to the start again.

Each time it calls the _ALIENMOVE proc the alien moves to the left. Each time
the _SHIPANIM proc is called the ship`s tail flame animates. This is an example
of animation without using AMAL. At the bottom of the proc we have the
collision detect routine which will trigger the Proc called _YOUREDEAD when the
alien makes contact with the ship. So add the procs:

        Procedure _ALIENMOVE
        M=M-5
        Bob 2,M,80,1
        End Proc

        Procedure _SHIPANIM
        For Y=18 To 21
        Bob 1,,,Y
        Wait Vbl
        Next Y
        End Proc

        Procedure _YOUREDEAD
        Boom
        For X=35 To 43
        Bob 1,0,80,X
        Wait 4
        Next X
        Pen 6 : Paper 0 : Centre `Kerboom! Yup, you`re dead!`
        Wait Key
        End
        End Proc

And that`s that. The _YOUREDEAD proc makes a boom noise and then animates the
explosion sequence from the sprite bank. This won`t work if the sprites are any
others than the ones specified, as they have specific images in the bank which
do certain jobs.

The sprite movement is a little jerky, even with double buffering. But you can
pep this up a little bit with careful program structure. As usual, with any
kind of coding planning is everything, and you have to carefully trace all your
procs and loops to make sure that nothing is happening out of turn and every
routine is working efficiently. Obviously all these problems vanish to a
certain extent when you compile a program.


Issue 56 ­ January 1993
` Shedding some light on the subject of windows

The Amiga is a WIMP system, and by this I don't mean it backs away from a
fight. The idea of a computer interface containing windows, icons, mice and
pointers was originally developed by Xerox at Palo Alto Research Centre.

When the Amiga was designed in 1984/5, GUIs were all the range, so the
designers incorporated a mouse and a GUI called Workbench in the new machine.
Only with Amos can we get the real power of windows and menus. Although they're
not the kind of windows you're used to in Intuition, they are as functional.

If the type of programs you want to write err towards productivity or
utilities, then you'll have to use the windowing functions of Amos. A window is
basically an independent little area of text and graphics on the screen. To
open a window on the screen you must employ the WIND OPEN command , like so:

        Wind Open 1,10,10,50,10

This, for example would open a window on to the screen (window 1) which would
have its top left corner at screen location 10,10 and would be 50 characters
wide by 10 characters deep. The point of this is that you can have two or more
windows on the screen at the same time, all with their own text and graphics,
like this:

        Screen Open 0,640,200,16,Hires
        Cls 0
        Flash Off
        Paper 7: Wind Open 1,0,0,40,20 : Print "This is window number 1..."
        Paper 4 : Wind Open 2,320,0,40,20 : Print "...and this is number 2!"
        Wait Key

Each window acts like a little version of the screen and anything you can write
to a screen you can send to a window. Although the windows you get in Amos
aren't the same as the kind of thing you are used to in AmigaDOS, they still
have a range of styles and shapes, and can be made to act like "real" windows
with the minimum of tweaking.

For example, you can re-size them and even add gadgets like Intuition, but all
this must be done manually as Intuition is not loaded when Amos is running,
alas (all this is changing with Amos Professional, of course).

Re-sizing is a good example so let's look at that. Let's make a window on the
screen which you can pull at the bottom right-hand corner by clicking on it
with the left mouse button. The window can be resized on the screen, and when
you let go of the button the window snaps to that shape.

In order to grab anything on the screen ­ unlike the very convenient Intuition
code which does it all for you ­ you have to draw a window and then describe a
AZone around it to sense the presence of a mouse-click.

Then once you've sensed it you have to see where it moves, and then resize the
window with WIND SIZE. In this example, we first open a hi-res screen and set
the colours as normal:

        Screen Open 0,640,256,16,Hires
        Paper 0 : Cls 0

The we activate WIND SAVE, which mean our windows are smart and don't screw up
anything on the screen below them. This is really groovy because it means you
can open a window over a game screen for example,. like an IFF file. and
nothing on the screen will be erased when you close the window:

        Wind Save

Next we RESERVE ZONE, which is what you do every time you are about to SET
ZONE. What this means is that if you Reserve Zone 1 you are basically saying
"look, I'm going to define a zone later on in the program, so allocate some
memory for it and I'll get back to you":

        Reserve Zone 1

Now we set up all the characteristics of the window we'll be defining, in this
case Window 1 is a 20 x 20 character window, whose top left corner is
positioned at location 10,50 on the screen. After that we set the BORDER and
TITLE TOP functions to describe a little bit more about the window, like the
title text, in this case "Grab my corner, man!" and the colours of the border:

        Wind Open 1,10,50,20,20,1
        Border ,0,4
        Title Top " Grab my corner, man! "
        Set Zone 1,10,50, To 10+160,50+160

The last bit is the interesting part. Next we open up the zone we promised
earlier. It covers the area taken up by the window, and does this by specifying
the Zone number, in this case 1, and the co-ordinates of the top left and
bottom right corners of the Zone.

Bottom right is set here by lazily multiplying the top left figures by 160,
that is to say 8 x 20, 8 being the number of pixels in a character, and 20
being the width of the window. The we're into the main loop of the program:

        Do
                If Mouse Key=1 and Mouse Zone=1
                        DX1=10 : DY1=50 : RESIZE ME
                        Reset Zone 1 : Set Zone 1,DX1,DY1 To DX2,DY2
                        ZX=(DX2-DX1)/8 : ZY=(DY2-DY1)/8
                        Wind Size ZX,ZY
                End If
        Print "Amos Almanac. Better than a punch up in the throat...   ";
        Loop

This checks for the MOUSE KEY and MOUSE ZONE functions to see if the mouse is
within the zone and if it has the left mouse button pressed down. If it does
the PROC called RESIZE_ME is activated.

The PROC then does all the work, creating a rubber band effect to show you
where the sides of the window are, altering the variables containing the window
co-ordinates, and checking to see if the mouse button has been released yet
with the WHILE WEND
loop:

        Procedure RESIZE_ME
                Shared DX1,DX2,DY1,DY2
                Gr Writing 2
                Repeat
                        If Mouse Key=1
                        DX2=X Screen(X Mouse) : DY2=Y Screen (Y Mouse)
                        0DX=DX2 : 0DY=DY2
                        While Mouse Key=1
                                Box DX1,DY1 To DX2, DY2
                                DX2=X Screen (X Mouse) : DY2=Y Screen (Y Mouse)
                                Box DX1,DY1 To DX2,DY2
                        Wend
                        Box DX1,DY1 To 0DX,0DY
                        Box DX1,DY1 To DX2,DY2 : GOTIT=True
                        If DX1>DX2 : T=DX1 : DX1=DX2 : DX2=T : End If
                        If DY1>DY2 : T+DY1 : DY1=DY2 : DY2=T : End If
                        End If
                Until GOTIT
                Gr Writing 1
        End Proc

Once the button is released the window is redrawn to the new size. When the new
co-ordinates have been stored the old Zone is cancelled and re-drawn to the new
size, and it's all ready to start again.

And there you have it, perfect windows, and not a single patch of putty in
sight. Now you can create multiple-windowed programs and multi-windowed games
too! How about a Dungeon Master clone in the PD then?


Issue 57 ­ February 1993
` How to put music to your creations

It seems that every program on the Amiga written with Amos has some lovely
piece of music to go with it. Don't you wish that you could make music like
that` Well you can.

It's tempting to steal other people's music off of bulletin boards, demos and
so on. But wait, don't touch that dial. The tracker programs you need to make
beautiful music are all public domain, with the exception of certain versions
of MED which are what they call "licenceware".

These disks costs a bit more than PD disks, but the author of the program gets
a royalty every time the program is sold. They almost always feature what we
call in the trade a "pattern editor" like you find on most modern drum machines
and certain Mini sequencers.

The sounds in trackers are always samples, like the kind you can make with your
own sound sampler, with the exception again of MED which also uses the sound
chip in the Amiga to create synthesized sounds, what we call "chip music". Most
trackers come with disks of sounds for you to get started. The way they work is
that you assemble patterns, short sequences of music lasting for 64 beats.

Then when you've made a pattern for your verse, chorus and other fill-ins etc,
you chain them all together to make a complete piece of music. You specify
which pattern you'd like to play and in what order, and the program plays each
pattern in turn to make meaningful music. Sometimes.

So for example you could have an intro on pattern 1, a verse on pattern 2, a
chorus on pattern 3 and a fill-in on pattern 4. The real kick of a pattern-
based sequencer is that you only have to input your patterns once and then they
can be played and arranged as many times as you like, rather than a more linear
system which would mean you'd have to type the tune in every time.

Creating pleasant music with a tracker is easy, as you can have four tracks (in
some cases even eight with programs like OctaMED Professional) and you can put
the notes in one at a time in what we call "step time", or play along with the
other tracks live on the keyboard in what is termed "real time".

Step time is easier for learners as you can fiddle about with each track of the
pattern until it sounds right, like typing words into a wordprocessor and
editing them until the spelling and syntax is perfect.

Once a piece of tracker music has been made, or produced, you can convert it to
Amos ABK format and load it into a program or into a bank in direct mode. The
Amos disks contain many different converters to serve most of the different
kinds of trackers such as Noisetracker, Soundtracker, StarTrekker, Protracker,
Games Music Creator, Sonix and so on.

All you do is run these very clever little Amos programs and they read in a
tracker file and spit out a ABK file onto disk ready to be loaded. Some of
these programs work fine, but the problem is that so many of the tracker
programs (being in the PD for some time now) have all been revamped and re-
written so that they are very different in format from the originals.

Some tracker tunes will not play properly once they've been converted. Usually
the reason is that the samples are too long or the system has changed. Either
the tracker has a pattern length which is variable and not fixed at 64, or it
stores its samples in a different way. Luckily, there are ways around this ­
see the programs documented in the box on this page for some ideas.

Do try to cultivate the use of tracker programs. You'll find they are not as
hard to use as you might think, and the results will be all your own work,
rather than just a steal from someone else.

A recent addition to the Déjà Vu licenceware library is Music Engine by Paul
Townsend (aka Technical Fred Software). This program lets you use tracker music
without having to convert it. What this program provides is an interface
between Amos and the Shell.

You can use this to play many different music file formats, and this is done by
running an appropriate "player program" which means you can hear the music
without having to convert it.

Once you've bought the Music Engine program from Déjà Vu, you are free to use
the source code, if it's for public domain,  shareware or licenceware use,
providing of course you acknowledge the source of your source.

If you want to use the routines in a piece of commercial software, however,
then you have to contact the programmers to arrange a suitable fee.  Music
Engine is a very powerful tool, and not just for driving music programs. The
trick is a very good one, and although it's handy for music, it's powerful
enough to run any program from the Workbench, effectively making your Amos
system multitask with other programs.

For more details of Music Engine (disk number LPD79) get in touch with Déjà Vu
Software, or write direct to: Technical Fred Software, 117 Hilton Lane,
Walkden, Worsley, Manchester M28 5TB. Phone or Fax: [phone].

Another fine program disk from the Amos PD Library is the MED Utils disk,
containing a copy of MED v2.13 and some convert utilities to make the
SoundTracker modules from MED more palatable to the ST-to-ABK converters. The
disk number is APD155

Lucky users of Amos Professional will know that, of course, Amos Pro is able to
use files from MED and Noisetracker (and it's various clones) directly using
libraries and features built into the program.  If you are using Amos Pro you
don't need to use a converter or any of the programs mentioned. You do however
need a copy of MED or Noisetracker to make the music in the first place.

I should also say that the most up to date version of MED isn't in the public
domain, but is available as licenceware, where the author gets a fee each time
the program is bought. You can get information about MED from Amiganuts United,
12 Hinkler Road, Southampton SO4 6FT


Issue 58 ­ March 1993
` Vectors ­ what they are and how to move them

Moving sprites on the screen is a pain in the bum, and no mistake. First you
have to get the damn things moving and then you've got to hold their hand every
step along the way, seeing what they hit, and then deciding how to bounce off
or explode depending on what the object you've hit is. It's like having kids,
or something.

Wouldn't it be so much nicer if you could just send an object off in a certain
direction and not worry about it until it actually does hit something? Well,
you can. But first a bit of maths (groan). No, don't turn the page. Maths is a
good thing. Keep that thought in mind and you'll last a lot longer as a
programmer!

Vectors are a method of moving objects around quickly and simply, with no
complex calculations or faffing about. They should be thought of as a change of
direction of an object (or point in space), rather than the usual way of moving
objects which is manually hiking them about using INC, DEC or things like
X=X+1.

It's the difference between picking a toy car up in the air and putting it
manually in another place (the old method) and pushing it along the ground and
letting go (like vectors). In Amos terms it works like this. As usual you use
the standard pair of variables to hold the X and Y co-ordinates of the sprite
or Bob position. So for example this is the vector demo program:

        Curs Off : Hide : Flash Off : Cls 0 : Ink 4,4 : Paper 0
        Input "What X ";DX#
        Input "What Y ";DY#

It's traditional to use the variables DX and DY, as these variables will tell
anyone reading your program that these are vectors. If your vectors are
designed to use an FPU (floating point unit), then append them with a hash or #
symbol.

In this demo program you start by inputting the x and y direction vectors ­
this has a result on the direction that the sprite will go. It's best to try a
range of numbers between -8 and 8 for each of the vectors. First the vectors
you require are accepted through the input command and stored in two variables
called DX and DY:

        Cls 0 : Bar 0,0 To 5,5
        Get Bob 1,0,0 To 6,6
        Cls 0

The Bob used in the program is grabbed from the screen using Get Bob, having
first been placed there using a Bar command. This is a good way of making
simple sprites without having to mess about with sprite editors or anything
silly like that. Next we want to talk about X and Y, which in this case are
floating point numbers so they are appended with #:

        X#=160 : Y#=100

Then the start position of the Bob is set to X=160 and Y=100, or slap dab in
the middle of the screen, as the screen we are looking at 320 by 200:

        While X#>0 and X#<320 and Y#>0 and Y#<200
           Bob 1,X#,Y#,1
           Wait Vbl
           X#=X#+DX#
           Y#=Y#+DY#
        Wend
        End

The While Wend loop moves the sprite in the direction given by the vectors.
After a while of running this program you'll be able to predict the precise
direction.

The Bob is moved until it reaches the edge of the screen, either less than
screen position 0 at the top or left of the screen, or screen position 320 or
200 to the right or bottom.

Each time the While Wend goes around, the DX and DY vectors are added to the
current co-ordinates, affecting the direction of the sprite. The DY and DX
vectors can be positive or negative, and the speed of the movement can be
varied too.

You can put random speeds and random directions into a sprite making it
possible to simulate the bouncing of a ball in a ping pong or squash game, or
you can even simulate gravity, if you have the right formulae.

This is a very cool and efficient way of shifting objects around, and with a
little bit of experimentation you can create very realistic movements for your
sprites with very small code. A lot of Aaron Fothergill's ten-liners (Amos
games written in just ten lines of code!) use vectors to chop down the amount
of code needed to do very intelligent things. If you haven't seen any of these
disks, then join the Amos Club right away!

Why aren't you a member? If you're into Amos you might like to join the club.
Write for details to Amos Club, 1 Lower Moor, Whiddon Valley, Barnstaple EX32
8NW.

You can even do vectors in 3D, but this is more complex (worth looking in to
though!). Obviously you have facilities at your disposal in Amos 3D to

translate objects in 3D, but a little bit of vector magic wouldn't hurt for
some really special effect.

The whole point is that vector riffs are small compared to those really big
routines which you can end up with when you try to do this stuff by hand.


                                    S O U R C E

This is a collection of Amiga Computing magazine's Amos columns, issues 42 to
58, Nov 1991 to March 1993!


                                 I M P O R T A N T

This file taken from a PC, it seemed to confuse the "?" and "`" characters,
when I moved them to the Amiga, I have done my best to correct them, but you
may find the odd one that still needs swapping.  Sorry I couldn`t do them all,
but Amos is too hard for me, i`m still on 68000 myself!



CALL THESE BOARDS...